fix: replace underpriced dapp-suggested and saved gas fees with suggested estimates - #9704

Explanation

Underpriced gas fees — a maxFeePerGas below (or barely above) the current base fee — produce transactions that are very unlikely to be included before fee conditions change further. They typically end up stuck as pending until eventually marked as failed (e.g. Transaction not found on network after timeout), with no actionable feedback to the user. Telemetry shows this is a meaningful contributor to dropped/timed-out transactions.

Two fee sources can produce such values, and nothing in the client validates either against current network conditions. This PR adds a feature-flag-gated staleness gate for both, at transaction creation time — the last point where fees can still be changed before signing.

1. Dapp-suggested fees (replaceUnderpricedDappGasFees flag)

Currently:

• updateGasFees uses initialParams.maxFeePerGas as-is.
• Gas estimation deliberately strips fee fields before calling the RPC node, so the node's own fee-cap validation never runs.
• GasFeePoller only refreshes fees for preset levels, so dappSuggested fees stay frozen while the confirmation is open.

A dapp that computes fees from stale data can therefore produce a signed transaction that cannot mine. With the flag enabled:

• A new shouldIgnoreDappGasFees check fires when the dapp-suggested maxFeePerGas (or a legacy gasPrice used as maxFeePerGas on EIP-1559 networks) is below the current low estimate. The low estimate is the floor rather than the raw base fee, since fees between the base fee and the low estimate have near-zero effective priority fee and no headroom for base fee movement, so they share the same failure mode.
• When it fires, the transaction falls through to the existing suggested (medium) fee logic for both maxFeePerGas and maxPriorityFeePerGas.
• userFeeLevel is set to medium instead of dappSuggested, which also opts the transaction into GasFeePoller refresh while unapproved.
• The original values remain available via dappSuggestedGasFees on the transaction metadata, so UIs can still display the site suggestion and users can revert via the edit modal.

Note: for transactions with complete dapp-suggested fees, getSuggestedGasFees previously skipped fetching estimates entirely. When the flag is enabled, estimates are now fetched for these transactions so the comparison can run — one additional gas fee estimate call per dapp transaction on enabled chains.

2. Saved (advanced) gas fee preferences (replaceUnderpricedSavedGasFees flag)

A saved custom preference is a static maxBaseFee captured at some point in the past; once the base fee rises past it, every transaction priced from it strands. Nothing else guards this source: the dapp gate deliberately excludes savedGasFees, and hasInitialGasFeeParams only protects transactions carrying explicit fee params — saved fees apply precisely when they don't. This is increasingly relevant as clients expand saved-preference usage (per-account custom gas settings persisted from the confirmation flow, and #9682 extending saved fees to wallet-initiated transfers).

With the flag enabled:

• After suggested fees are fetched, if the saved preference has a custom maxBaseFee below the current low estimate, the saved preference is ignored for this transaction and the suggested (medium) values are used instead.
• Level-based saved preferences (low/medium/high) are never touched — they track current estimates by construction.
• userFeeLevel becomes medium instead of custom, with the same GasFeePoller refresh benefit.
• No fetch-path changes needed: transactions eligible for saved fees carry no fee params, so estimates are already fetched.

Guards / fail-open behavior (both gates)

Fees are kept unchanged when: the respective feature flag is not enabled for the chain (both default to disabled; per-chain rollout via perChainConfig with default fallback, mirroring timeoutAttempts); the transaction is internal (dapp gate; swaps/bridges are priced by the aggregator/relay); the fee is at or above the low estimate; or estimates are unavailable / not fee-market type.

The product decision (saved-fees gate)

Overriding a value the user saved is a stronger intervention than overriding a dapp's computed value. Three defensible behaviors when the saved-fees gate fires: (1) silently use suggested fees (this PR's behavior), (2) use suggested fees + surface an alert ("your saved gas setting is below current network fees"), (3) keep the saved value + warn only. The flag ships disabled, so this can be settled before enablement.

An argument for intervening (1 or 2) rather than deferring entirely to the saved value: saved preferences already do not grant full autonomy. The controller already ignores them for swaps and bridges (SAVED_GAS_FEES_IGNORED_TRANSACTION_TYPES, #9401/#9682) — explicitly because a saved fee could underprice aggregator-priced transactions — and already yields them to explicit fee params (hasInitialGasFeeParams, #8993). The established principle is that saved preferences apply where they can work and yield where they would predictably break the transaction. A custom maxBaseFee below the current low estimate is the clearest instance of the latter — this extends existing precedent rather than setting new one.

References

• Prior art for saved-fee exclusions: fix: ignore saved advanced gas fees for bridge transactions #9401, fix(transaction-controller): scope saved gas exclusions to swaps and bridges #9682, feat(transaction-controller): support saved gas fee levels #8993
• Known edge case (fee bump vs. dapp max-spend arithmetic) and proposed balance-clamp refinement: see PR comment below — it applies to both gates.

Checklist

• I've updated the test suite for new or updated code as appropriate
• I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
• I've communicated my changes to consumers by updating changelogs for packages I've changed
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them